AWSリソースの命名規則を考えてみた (2024年版)

リソース名に規則性を持たせたい

こんにちは、のんピ(@non____97)です。

皆さんはAWSのリソース名に規則性を持たせたいと思ったことはありますか? 私はあります。

AWSを使っている中で「命名規則を設定した方がいい」もしくは「設定しなければならない」場面があります。

利用し始めはリソース数や管理、使用するメンバーが少なくなんとかなることもあります。しかし、規模が大きくなってくると、命名規則が設定されておらず無秩序にリソース名が設定されていると、オペレーションミスが発生したり、構成を把握するのに時間がかかったりします。

そんな命名規則を設定するのにあたって参考になるのが以下記事です。

https://dev.classmethod.jp/articles/aws-name-rule/

こちらの記事をベースに命名規則を改めて考えてみた時に、考慮が必要な内容をまとめてみました。

以降、AWSリソースの命名規則についてまとめた基本設計書の例を紹介します。

記載した内容に対する一言コメントは以下ブロックに書いています。

基本設計表記例

1. 目的

命名規則を定める目的は以下のとおり。

目的	説明
リソース構成の可視化	以下を容易にする - リソースの役割や用途の判別 - システム全体の構成把握 - リソースの識別性向上による誤操作防止
運用効率の向上	以下の運用作業を効率的に実施する - リソースの検索とフィルタリング - 複数リソースの一括操作 - 運用自動化
セキュリティ管理の強化	きめ細かな権限制御

命名規則によって以下の識別を明確にする。

• 対象システム
• 環境 (本番、ステージング、開発など)
• AWS リソース
• 役割
• 用途

2. AWSリソースの命名規則

2.1. 命名規則の基本ルール

命名規則の基本ルールは以下のとおり。

• 単語間はハイフン (-) で結ぶ
  • ハイフンが使用できない場合はアンダースコア (_)を使用する
• 英小文字と数字のみを使用
• 原則、マルチバイト文字、英大文字、アンダースコア (_)、その他の記号は使用しない
• 原則、{System}-{Env}-{ResourceType}-{Summary}というフォーマットに沿った名前を付与する

SystemやEnvなど命名規則の各要素の詳細は以下のとおり。

要素	詳細
System	このリソースによって構成されるシステム名 本プロジェクトではexampleを使用する
Env	リソースの環境名 - 本番環境 : prod - 本番DR環境 : proddr - ステージング環境 : stg - ステージングDR環境：stgdr - 開発環境 : dev 複数環境で共通的に使用するリソースは重要度の最も高いリソースの環境名を使用する e.g.) 本番環境と本番DR環境、ステージング環境で共通的に使用するリソース → prod
ResourceType	リソースの種類を表す略語 リソースIDの先頭に付けられているもの、もしくはARNのresource-type、serviceに該当する e.g.) - sg-1234567890ab → sg - arn:${Partition}:iam::${Account}:role/${RoleNameWithPath} → role - arn:${Partition}:ec2:${Region}:${Account}:instance/${InstanceId} → ec2 場合によっては複数単語で構成される e.g.) tgw-attach-1234567890ab → tgw-attach 長いものや分かりにくいものは分かりやすい名前を付与する e.g.) - arn:${Partition}:elasticloadbalancing:${Region}:${Account}:loadbalancer/app/${LoadBalancerName}/${LoadBalancerId} → alb - arn:${Partition}:autoscaling:${Region}:${Account}:autoScalingGroup:${GroupId}:autoScalingGroupName/${GroupFriendlyName} → asg
Summary	リソースの役割、要旨を表す短い文言を任意で記述する SubnetTypeやRole、Usageなど細かく分類される
SubnetType	サブネットの種類 - インターネットとインバウンド/アウトバウンドでルーティング可能 → public - インターネットへアウトバンドでルーティング可能 → private - インターネットとのルーティング不可 → isolated
Role	リソースの機能的な役割 e.g.) Webサーバ → web、DBサーバ → db 複数単語の場合はハイフン(-)で結ぶ e.g.) Web管理サーバ → web-admin
Usage	リソースの用途 e.g.) - 各種エンドポイント配置用 → endpoint - オンプレミスとVPC間通信管理用 → ns (North-South) - VPC間通信管理用 → ew (East-West) - SMBクライアント用 → smb-client
AzId	AZ IDの末尾 e.g.) apne1-az1 → az1 複数リージョンにデプロイさせActive/Activeで動作させるリソースの場合はAZ IDをそのまま使用することを検討する
Site	接続拠点名 e.g.) 東京拠点 → tokyo

2.2. 命名規則の適用例外

上述の命名規則の基本ルールの適用範囲外は以下のとおり

適用範囲外のリソースの条件	例
AWSのリソース以外	- Amazon FSx for NetApp ONTAPのSnapshot Policy
階層構造で名前付けを行うことが一般的なリソース	- CloudWatch Logsロググループ - SSM Parameter Store - Secrets Manager
命名規則に制約がある場合	- AWS WAFのログの出力先とするS3バケット名
自動で作成されるリソース	- Service-Linked Role - EC2インスタンスやRDS DBインスタンスのENI - EC2インスタンスのEBSボリューム
以下条件に当てはまる、あるリソースに従属しているリソース - 単独では存在できない - 親リソースの削除と共に自動的に削除される - 親リソースの一部として管理される	- IAMロールのインラインポリシー - S3のライフサイクルルール
デフォルトで作成されるリソース	- Security Group - NACL - DHCP Options Set
バックアップ	- EBSスナップショット - RDS DBスナップショット - AMI
名前の設定を行うのに設定コストがかかるリソース	- AWS CDK L2 ConstructでDefault Construct以外に自動作成されるリソース
そのリソース名をベースに検索、管理しないと思われるリソース	- VPC Flow Logs

2.3. リソースごとの設定例

リソースごとの設定例は以下のとおり。

AWSリソース	命名規則	例	備考
VPC	{System}-{Env}-vpc	example-prod-vpc
Subnet	{System}-{Env}-subnet-{SubnetType}-{Usage}-{AzId}	example-prod-subnet-private-endpoint-az1
Route Table	{System}-{Env}-rtb-{SubnetType}-{Usage}-{AzId}	example-prod-rtb-private-endpoint-az1	各AZのサブネットごとにルートテーブルを分割しないのであれば、{AzId}は不要
Security Group	{System}-{Env}-sg-{SubSystem}-{Role}	example-prod-sg-nextcloud-web
Network ACL	{System}-{Env}-acl	example-prod-acl
DHCP option sets	{System}-{Env}-dopt	example-prod-dopt
Internet Gateway	{System}-{Env}-igw	example-prod-igw
NAT Gateway	{System}-{Env}-natgw-{AzId}	example-prod-natgw-az1
Elastic IP	{System}-{Env}-eip-(natgw-{AzId}|nlb)	example-prod-eip-natgw-az1
VPC Endpoint	{System}-{Env}-vpce-{Service}-(interface|gateway|resource|sn)	example-prod-vpce-logs	(interface|gateway|resource|sn) はお好みで
Managerd Prefix List	{System}-{Env}-pl-{Usage}	example-prod-pl-smb-client
Transit Gateway	{System}-{Env}-tgw	example-prod-tgw
Transit Gateway attachment	{System}-{Env}-tgw-attach-(vpc|vpn-{Site}|dxgw-{Site})	example-prod-tgw-attach-vpn-tokyo	{System}-{Env} はTransit Gateway attachmentの接続先リソースのものを使用
Transit Gateway route table	{System}-{Env}-tgw-rtb-{Usage}	example-prod-tgw-rtb-ns-ew	{Usage} は通信の関係性を指す
Customer Gateway	{System}-{Env}-cgw-{Site}	example-prod-cgw-tokyo
Site-to-Site VPN	{System}-{Env}-vpn-{Site}	example-prod-vpn-tokyo
Direct Connect Gateway	{System}-{Env}-dxgw-{Site}	example-prod-dxgw-tokyo
RAM	{System}-{Env}-ram	example-prod-ram
EC2 Instance	{System}-{Env}-ec2-{SubSystem}-{Role}	example-prod-ec2-nextcloud-web	Auto Scailingを使わないクラスター構成の場合EC2インスタンス毎に末尾に連番を付与する (-001 や -002など)
Key Pair	{System}-{Env}-keypair-{SubSystem}-{Role}	example-prod-kerypair-newxcloud-web
ELB	{System}-{Env}-(alb|nlb|gwlb)-{SubSystem}-{Role}	example-prod-alb-newxcloud-web	複数のサブシステムでALBを共有する場合は{SubSystem}-{Role}は不要
ELB Target Group	{System}-{Env}-elb-tg-{SubSystem}-{Role}	example-prod-elb-tg-newxcloud-web
ACM	{System}-{Env}-acm-{SubSystem}	example-prod-acm-nextcloud-web
S3 Bucket	{System}-{Env}-bucket-{Usage}-{AccountId}	example-prod-bucket-vpc-flowlogs-123456780012	公開するS3バケットには {AccountId} を付与しない
IAM Role	{System}-{Env}-role-{SubSystem}-{Role}	example-prod-role-nextcloud-web
RDS DB Instance	{System}-{Env}-rds-{SubSystem}	example-prod-rds-nextcloud
RDS Subnet Group	{System}-{Env}-rds-sbng	example-prod-rds-subgrp
RDS Parameter Group	{System}-{Env}-rds-pg-{SubSystem}	example-prod-rds-pg-nextcloud
RDS Option Group	{System}-{Env}-rds-og-{SubSystem}	example-prod-rds-og-nextcloud
FSxN File system	{System}-{Env}-fsxn	example-prod-fsxn
FSxN SVM	{System}-{Env}-svm-{SubSystem}	example-prod-svm-general
FSxN Volume	{System}{Env}fsvol{SubSystem}{JunctionPath}	example_prod_fsvol_general_poc	{JunctionPath} はボリュームのジャンクションパス ジャンクションパスに含まれる/ は _ に置換
KMS	{System}-{Env}-key-{SubSystem}	example-prod-key-nextcloud

参考情報

• 弊社で使っているAWSリソースの命名規則を紹介します | DevelopersIO

3. タグ

上記で定めた規則は各種タグの値として設定する。

運用性向上のため以下のタグを全リソースに共通で付与する。

タグキー	タグ値	備考
Name	{System}-{Env}-{ResourceType}-{Summary}	命名規則で定めたリソース名称 ※ 「2.2. 命名規則の適用例外」に当てはまるリソースには上述のタグを付与しない
Env	(prod|proddr|stg|stgdr)	環境名 - 本番環境 : prod - ステージング環境 : stg - 本番DR環境 : proddr - ステージングDR環境 : stgdr
System	example	システムを識別可能な文字列
SubSystem	example	サブシステムを識別可能な文字列
Project	project	プロジェクトを識別可能な文字列
CmBillingGroup	project	クラスメソッドポータルサイトでコスト分析に使用する

また、何らかの処理を自動化している場合はタグを活用し、対象システムやタスク実行時間を制御する。

タグキー	タグ値	備考
BackupSelection	example-prod-backup-selection	AWS Backupによるバックアップ取得管理用タグ AWS BackupのBackup Selectionにて、本タグが付与されたリソースのバックアップを取得するよう設定する
SsmPatchTarget	(true|false)	SSM Patch Manager適用制御用タグ SSM Patch Managerにてこのタグが付与されてるリソースに対してパッチ適用をするように設定する
SsmHostManagementTarget	(true|false)	SSM Host Management制御用タグ SSM Quick Setupにてこのタグが付与されてるリソースに対してSSM Agentのアップデートやインベントリ収集をするように設定する

参考情報

• AWS タグの活用方法と命名ルールを考える | DevelopersIO
• ベストプラクティスと戦略 - AWS リソースのタグ付けとタグエディタ
• カテゴリのタグ付け - AWS リソースのタグ付けとタグエディタ

後から命名規則を設定するのは大変なので早めに決めよう

AWSリソースの命名規則を改めて考えてみました。

後から命名規則を設定するのは大変なので早めに決めましょう。特にセキュリティグループやRDS DBインスタンス、ALBなど設定した名前が物理IDとなるものは後から変更する際のハードルが非常に高いです。

この記事が誰かの助けになれば幸いです。

以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!